Version 3 don't will be published with PhysicsBody replacement?

version 3 still in early status, and should contains physics2d when publish.

Will be nice if we have a single json library easy to use, like nlohmann/json instead of two.

Will be nice if we have a single json library easy to use, like nlohmann/json instead of two.

The nlohmann/json easy to use, but performance not good.

I need rapidjson performance as well, please do not remove 😅

I don't understand how a JSON lib in a game engine needs such an absurd performance, since things like that are used in few moments, like loading or saving things at specific times.

In our app (Ubook) that uses JSON all the time and processes thousands of JSON data with thousands of records, the processing is instantaneous, even in huge JSON data and we use nloman/json. Before we used rapid, but it doesn't have as many features, requiring other libs to be used and more things to be maintained, decreasing efficiency in exchange for NOTHING.

For me, it would make sense to keep a single lib that is easy to use and that for our scenario here at Axmol, will not affect anything in practice.

Here is my opinion based on my reality as someone who uses this in practice and in large volumes, both on Android and iOS, as well as on Apple Watch and Apple TV and also on the desktop.

I need rapidjson performance as well, please do not remove 😅

If it is removed from Axmol, then you can easily add it into your own projects with a few lines of CMake code, and nothing else has to change in your projects.

I don't understand how a JSON lib in a game engine needs such an absurd performance, since things like that are used in few moments, like loading or saving things at specific times.

Your projects may not require the speed of libraries like rapidjson, but that may not apply to projects by others, since they may have completely different requirements.

In our app (Ubook) that uses JSON all the time and processes thousands of JSON data with thousands of records, the processing is instantaneous, even in huge JSON data and we use nloman/json. Before we used rapid, but it doesn't have as many features, requiring other libs to be used and more things to be maintained, decreasing efficiency in exchange for NOTHING.

There are cases where the speed of parsing needs to be as quick as possible, such as in event handlers, comms response handlers, etc. etc.. In these cases, speed definitely does matter, and it is quite noticeable if the parsing takes too long.

For me, it would make sense to keep a single lib that is easy to use and that for our scenario here at Axmol, will not affect anything in practice.

That may be the case for your own projects, but again, it may not apply to projects by others. Also, just because a specific library works for you, it doesn't mean that it is appropriate for it to be used in Axmol.

Here is my opinion based on my reality as someone who uses this in practice and in large volumes, both on Android and iOS, as well as on Apple Watch and Apple TV and also on the desktop.

That's all well and good, and as you stated, your opinion is based on the requirements of your own projects, but it's not really appropriate to make statements about what other developer should or shouldn't use in their projects, because you really don't know what their requirements are.

The engine should bundle whatever json library (or libraries) it requires, but that in no way forces the developers using Axmol to also use those libraries. Developers are free to use whatever library they want to use.

On a side note, many developers who use Axmol for their released projects have never posted on this discussion board, and may not even read these threads, so unfortunately, it would be hard to get their feedback on such things.

Finally, maybe yyjson, speed fast and support read/write and dom style APIs, axmol can make a thin c++ wrapper

The problem with nlohman/json is not only its lack of runtime speed but it's also a huge >10k thousand long header only library, making compilation also slower. its really one of the worst options you can choose. In modern C++ there is a clear new winner in my opinion: glaze is a modern C++ json library with automatic serialization/deserialization, making it really convenient for simple use cases. The performance is on par with simdjson. For non reflection uses, there is generic json which is similar to nlohman in that regard.

There are a few cons, thought:
it only supports c++23
Needs recent compiler versions
Not sure if it has been tested in platforms like wasm, ios

Hi,

Glaze is nice too. Their syntax is like nlohman/json and is easy to use.

My concern is always to keep the engine as easy as possible for people to use. It's better to use Glaze, which already does everything, than to have to adopt several libraries and increase complexity, lowering the barrier to entry.

I tried glaze, but compile fails
EDIT: seems it fix msvc compile issues recently

I was wondering if v3 wouldn't be a good time for more breaking changes, like getting rid of the .h extension for the headers in favor of .hpp or something like this, such that we can finally know that it is C++ without opening the file. What do you think?

In the same vein, what do you think of enforcing the code formatting in the CI by running a clang-format check on each PR?

This PR is for ci check only, since we try to update branch mangement: enable ci for dev/, release/, this PR can closed, v3 roadmap, please see: #2650

I was wondering if v3 wouldn't be a good time for more breaking changes, like getting rid of the .h extension for the headers in favor of .hpp or something like this, such that we can finally know that it is C++ without opening the file. What do you think?

In the same vein, what do you think of enforcing the code formatting in the CI by running a clang-format check on each PR?

auto run clang-foramt check is a good idea.

I was wondering if v3 wouldn't be a good time for more breaking changes, like getting rid of the .h extension for the headers in favor of .hpp or something like this, such that we can finally know that it is C++ without opening the file. What do you think?
In the same vein, what do you think of enforcing the code formatting in the CI by running a clang-format check on each PR?

auto run clang-foramt check is a good idea.

should finish by PR: #2654

If I understood #2654 correctly it creates a new commit which formats the code on each PR. This is imho a bad solutions as those commits will pollute the history with meaningless changes, complexifying git blame and git bisect, for example. Still imho, the pipeline should just check that the code is formatted, and let the committer rewrite its commits with adequately formatted code.

If I understood #2654 correctly it creates a new commit which formats the code on each PR. This is imho a bad solutions as those commits will pollute the history with meaningless changes, complexifying git blame and git bisect, for example. Still imho, the pipeline should just check that the code is formatted, and let the committer rewrite its commits with adequately formatted code.

at least, first time, we can format all sources